[レポート]Developers.IO 2019 Tokyo「ダイソーが進めるクラウド活用と内製化のご紹介」」 #cmdevio

初めての方、初めまして。そうでもない方、お久しぶりです。

タケダノです。

全国津々浦々で開催されているDevelopers.IO 2019、2019/11/01にその東京編が開催されました。

• 【11/1（金）東京】国内最大規模の技術フェス！Developers.IO 2019 東京開催！AWS、機械学習、サーバーレス、SaaSからマネジメントまで60を越えるセッション数！

さて、今回その中で「ダイソーが進めるクラウド活用と内製化のご紹介」というセッションについて参加したのでレポートします。

 

登壇者について

登壇者は株式会社大創産業 情報システム部 課長 丸本健二郎 氏 セッションの概要は以下の通りです。

ダイソーは、世界27カ国、5,270店舗（2018年3月時点）を展開しています。取扱商品は約70,000 種類。毎月約 700 種類の新商品を開発しています。本セッションでは、オンプレ開発をしていたダイソーが、どうやってサーバーレスファーストの組織に変わっていったのか、きっかけ、メンバーのマインド、コストについて、そして、ダイソーのサーバーレスBI（Amazon QuickSight）、とサーバーレスインターフェイス基盤の事例をお話します。

実はタケダノはダイソーさんと同じ広島県出身ということもあって、とても興味深くセッションに参加させて頂きました。

発表について

• 会社紹介：店舗5,542・売上4,757奥商品70,000・国と地域28。
• キャリア：SIer - 外資 - ダイソー。

１．ベンダー任せの幕開け

• ダイソーに入社した6年前：社内の誰に聞いてもしらない。
• システム全体構成を把握しようとしても無かった。
• システム一覧も無かった。
• 企画書もない。
• 要件定義書もない。
• 設計書はあるけど、古くて今と違います。回収をお願いしてもリソースがない。
• 改修コストはいくらか調べると5倍くらい違った。
• 処理が遅いのでチューニングしようとしたら、教え得てあげると御礼は言われるが頼むと断られる。
• 構築したいシステムを提案すると1億円の案件にするよう提案される。
• 他の案件でヒトが取られていく。
• 700システムが大型パッケージとマクロが同一レベルで語られてしまった。
• 当時I型人材（エキスパート）からT型人材（全体最適）への転身。

２．内製化の船出

• パレート最適：2割の商品で8割の売上を創り出す。
• 現場は商品数・新商品など困っていた。
• ダイソーの場合店舗×商品×需要予測をすると、105億レコード必要になる。
• ベンダーさんに聞いても回答が得られなかった。
• 難しいっていうのは誰でも出来る。
• ベンダーが見ているところと、ユーザーが見るべきところの違いが、「そもそも論」としてあった。
• 出来ない出来ないと言われるので自分たちで作り始めた。

３．最初の航海（内製）はモノリシックで失敗

• 当初狙っていたことはそれぞれサブシステムにするという構想を持っていたが、狙った物と出来上がった物が異なっていた。
• コンウェイの法則：1つの組織で何かを作ると同じ物をつくってしまった。
• 5つのプロジェクトをバラバラにすべきだった。
• マイクロサービスを狙っていたのにモノリシックな物を作ってしまっていたことを気付いた。
• さらにはオンプレミスのサイジングでは、リソースの富豪（余剰）＞平民＞貧民（不足）時代を繰り返す。
• クラウドなら必要なときに必要なリソースを利用可能。
• NoSQLに出会ったAmazon Redshiftはデータ件数が増えてもれっかしないことが検証できた。

４．マイクロサービス、CI/CDを導入

• POSデータ保持システムを作った。
• 受取、チェック、ためる、参照（送）、参照(受）。
• インターフェイス統合システムを作った。
• 出来上がった大きなモノリシックにメスを入れるのでは無くIF(バイパス)開発をしてマイクロサービスを作った。
• CI/CDを何故入れたのか？それは当初本番環境にはバグがでたので、開発機に探しにいくと再現性がなかったから。
• 本番環境にしか起こりえないことがあった。
• ①ソース管理の実施を始めた。
• ②検証環境＆リリース手順書を導入した。
• サーキットブレーカーを作っていたので止まったが冷や汗だった。
• 原因はリリースミス。
• リリース手順書は作っていた。
• 1人でやるとミスる2人で見てもミス。
• バグの原因、バグの割合は半分。
• その結果デプロイ自動化することで解決した。
• テストにメスを入れた。
• ただし全てではなくて絞って対応した。

１．修正が頻繁 - CI ２．品質が求められる - CI ３．王道テスト - CI ４．採取結果のと都合 - CI ５．全て - CD

５．サーバーレスの圧倒的な力

• Whyサーバーレス
• 特化型のサービスを活用するため。
• 全てを満たすことは難しい。
• オンプレは全てを管理する必要がある。
• 仮想サーバーはハードの管理が不要。
• サーバーレスはビジネスに集中できる。

６.Why AWS

• テクノロジーの差はAWSもGoogleもAzureも大差ない。
• あるのは情報量の差。
• だからクラスメソッドに助けられている。
• さらにはベンダーの数。
• 時間は有限であるだから狭く深くということを考えてAWSに絞った。

７．事例

• システム間もスパゲッティ。
• 書くインターフェイスの問題。
• プロトコルはバラバラ。
• バージョンもバラバラ。
• 上長対策されていない物も有る。
• なので自分たちが作ったのはシステム間を疎結合を実現するためのシステム。

８．まとめ

• ベンダー任せ時代と内製時代を対比的に例示。
• 売上を本当に作る、攻めの武器を作れるようになった。

本業に専念するために社内のエンジニアリソースを最適配分するような、なされた苦労が無駄ではない非常に良いお話でした。 丸本様貴重なお話をありがとうございました。